docs: reclassify Tier 5 -> Tier 2 (Platform) with Tier-5 dashboard surface#110
Conversation
… Tier-5 surface; add meta endpoints and dependencies Stacked follow-on to PR #106 (ADR-001 + executor registry). Documentation-only PR that brings the compliance triad and `/api/v1/status` in line with the ADR-001 amendment that landed on `feat/meta-executors-registry`. CHARTER.md / CHITTY.md / CLAUDE.md - Canonical phrasing: "Tier 2 (Platform) with Tier-5 dashboard surface" everywhere a tier is declared. - RY (Authority) row rewritten to reflect sovereignty enforcement + intent execution + multi-source ingest. No longer a pure consumer. - API contract gains the one real new endpoint introduced by #106: POST /api/v1/intents/:id/execute. Per the global no-fake-endpoints rule, the planned intent CRUD (POST /api/v1/intents, GET .../:id, GET ..., GET /api/v1/executors) is NOT documented here because it isn't implemented; it will be added when the routes are. - New Executor Registry table with canonical URI chittycanon://core/services/chittycommand/executors/{intent_type}. Lists the one executor that actually self-registers today (update_obligation_status). mercury_payment is flagged as a tracked future executor with REAL-MONEY constraints (fresh autonomous sovereignty, USD 500 per-intent cap) and explicitly NOT documented as registered. - New Cluster Runtime section: daemon is launchd/systemd, NOT a Worker; per-node L-type ChittyIDs register as sub-channels via agent.chitty.cc/api/v1/channels, NOT in the main ChittyRegister payload. - Dependencies expanded: ChittyTrust, ChittyID, chittyagent-orchestrator, chittyagent-tasks, chittyagent-ch1tty added. ChittyConnect entry expanded to call out ContextConsciousness + MemoryCloude (forever context) and sensitive-intent secret brokerage. - Compliance section flags the ChittyID re-mint as required operator action (T → P-Synthetic) and explicitly defers /health real-probes and tail_consumers wiring to separate PRs. - MCP tool count reconciled to 50 (CLAUDE.md was already correct; CHARTER/ CHITTY updated from stale "48"). src/index.ts - /api/v1/status returns tier: 2 plus tierSurface phrasing and a meta.endpoints array listing the registered intent-execute route. No other route, middleware, or handler touched. src/routes/meta.ts - /api/v1/canon returns tier: 2 + tierSurface so the public canon view matches /status and the docs. Same handler signature; no behavior change. Not in this PR (deferred): - Real-dependency /health probes (separate PR). - tail_consumers wiring to chittytrack (separate observability PR). - ChittyRegister payload submission (operator action; blocked on re-mint). - Re-mint of service ChittyID as P-Synthetic (operator action). - Intent CRUD endpoints and /api/v1/executors enumeration (future PRs). Compliance coverage: - Addresses: tier reclassification, RY language, meta endpoint surface, executor URI registry, dependency expansion, cluster sub-channel declaration (items 1, 4, 5, 7, 8 of the registration-readiness audit). - Remaining (out of scope): registration submission (item 2, operational), real /health (item 3, separate PR), tail_consumers (item 6, separate PR), P-type ChittyID re-mint (item 9, operator action). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
chittycommand | f67f303 | Jun 04 2026, 01:00 PM |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
To use Codex here, create a Codex account and connect to github. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dade6fe8de
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - **Organization**: CHITTYOS | ||
| - **Domain**: command.chitty.cc | ||
|
|
||
| Per [ADR-001](docs/architecture/ADR-001-meta-orchestrator-extension.md), ChittyCommand is reclassified from Tier 5 Application to **Tier 2 (Platform) with Tier-5 dashboard surface**. The platform tier covers the meta-orchestrator (`meta/`), executor registry, sovereignty gate, and cluster daemon (`daemon/`). The Tier-5 surface is the existing user-facing dashboard + ActionAgent + MCP at `command.chitty.cc`. Both run from the same worker; the dashboard is one consumer of the platform among many. |
There was a problem hiding this comment.
This sentence says the platform daemon and Tier-5 surface “both run from the same worker,” but the new Cluster Runtime section added below states the persistent daemon/ is not a Cloudflare Worker and runs as a supervised launchd/systemd process on ChittyServ nodes. In the compliance charter this gives operators two conflicting deployment models for the Tier-2 reclassification, and following the classification text would incorrectly model the daemon as part of the Worker deploy artifact.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 4eba80a. Charter Classification now explicitly states the Worker (src/, meta/ HTTP, dashboard, ActionAgent, MCP) and the persistent daemon (daemon/, supervised launchd/systemd, not a Worker) are two distinct runtimes that share the same Neon DB — removing the contradiction with the Cluster Runtime section.
Addresses Codex P2 on PR #110: the previous wording said the Tier-2 platform and Tier-5 surface 'both run from the same worker', which contradicts the Cluster Runtime section stating daemon/ runs as a supervised launchd/systemd process, not as a Worker. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
To use Codex here, create a Codex account and connect to github. |
… submission runbook (#111)
|
|
To use Codex here, create a Codex account and connect to github. |
|
|
To use Codex here, create a Codex account and connect to github. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e77033e9f4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| The actual injection uses `op run` per the operator manifest. The template below shows the request shape — do NOT run it verbatim with raw env vars. | ||
|
|
||
| ```bash | ||
| jq '.registrationToken="$CHITTY_REGISTER_TOKEN" | .service.chittyId="$NEW_CHITTYID"' \ |
There was a problem hiding this comment.
If an operator follows the production instruction below to wrap this command under op run, this jq filter writes the literal strings $CHITTY_REGISTER_TOKEN and $NEW_CHITTYID into the JSON; shell variables are not expanded inside the single-quoted jq program, and jq --help shows --arg name value is the supported way to bind string values into $name. That means the registration payload would be submitted with the placeholder token/id rather than the minted P-Synthetic ChittyID, causing registration rejection or bad service metadata.
Useful? React with 👍 / 👎.
| { "path": "/api/v1/connect/discover", "method": "POST", "description": "Resolve service URL via ChittyConnect", "authenticated": true }, | ||
| { "path": "/api/v1/ledger/evidence", "method": "GET", "description": "List evidence for a case via ChittyLedger", "authenticated": true }, | ||
| { "path": "/api/v1/ledger/record-custody", "method": "POST", "description": "Record custody entry for an evidence_id", "authenticated": true }, | ||
| { "path": "/api/v1/timeline/:caseId", "method": "GET", "description": "Unified case timeline (facts, deadlines, disputes, docs)", "authenticated": true }, |
There was a problem hiding this comment.
This payload registers /api/v1/timeline/:caseId, but the route mounted under /api/v1 is timelineRoutes.get('/cases/:caseId/timeline', ...) in src/routes/timeline.ts:20 via src/index.ts:162, so clients discovering this registration entry will hit a 404. The payload should advertise /api/v1/cases/:caseId/timeline unless the worker route is changed too.
Useful? React with 👍 / 👎.
| { "path": "/api/v1/litigation/synthesize", "method": "POST", "description": "AI fact synthesis from raw notes", "authenticated": true }, | ||
| { "path": "/api/v1/litigation/draft", "method": "POST", "description": "AI email drafting from synthesized facts", "authenticated": true }, | ||
| { "path": "/api/v1/litigation/qc", "method": "POST", "description": "AI risk scan of draft vs source notes", "authenticated": true }, |
There was a problem hiding this comment.
These registration entries put the litigation endpoints under /api/v1/litigation/*, but src/index.ts:147 mounts litigationRoutes at /api/litigation and the route file defines paths such as post('/synthesize') in src/routes/litigation.ts:28. As submitted, the registry would publish three authenticated endpoints that do not exist on the worker.
Useful? React with 👍 / 👎.
| { "path": "/api/v1/jobs", "method": "POST", "description": "Enqueue scrape job", "authenticated": true }, | ||
| { "path": "/api/v1/jobs/:id", "method": "GET", "description": "Scrape job details", "authenticated": true }, | ||
| { "path": "/api/v1/jobs/:id/retry", "method": "POST", "description": "Retry failed scrape job", "authenticated": true }, | ||
| { "path": "/api/v1/jobs/dead-letters", "method": "GET", "description": "Dead letter queue", "authenticated": true }, |
There was a problem hiding this comment.
The implemented dead-letter route is mounted under /api/v1 and defined as jobRoutes.get('/jobs/queue/dead-letter', ...) in src/routes/jobs.ts:39, not /api/v1/jobs/dead-letters. Registering this path will make the service catalog point operators to a 404 for dead-letter inspection.
Useful? React with 👍 / 👎.
| { "path": "/api/v1/jobs/:id", "method": "GET", "description": "Scrape job details", "authenticated": true }, | ||
| { "path": "/api/v1/jobs/:id/retry", "method": "POST", "description": "Retry failed scrape job", "authenticated": true }, | ||
| { "path": "/api/v1/jobs/dead-letters", "method": "GET", "description": "Dead letter queue", "authenticated": true }, | ||
| { "path": "/api/dashboard/summary", "method": "GET", "description": "Dashboard summary with urgency scores", "authenticated": true }, |
There was a problem hiding this comment.
dashboardRoutes only defines get('/') in src/routes/dashboard.ts:8 and is mounted at /api/dashboard in src/index.ts:132; there is no /summary child route. Registering /api/dashboard/summary means registry consumers will call a non-existent dashboard endpoint instead of the implemented aggregate view.
Useful? React with 👍 / 👎.
| { "path": "/api/cashflow", "method": "GET", "description": "Cash flow analysis and projections", "authenticated": true }, | ||
| { "path": "/api/sync", "method": "POST", "description": "Manual data sync trigger", "authenticated": true }, |
There was a problem hiding this comment.
The worker mounts cashflowRoutes at /api/cashflow and syncRoutes at /api/sync, but those routers only expose concrete children such as GET /projections (src/routes/cashflow.ts:10) and POST /trigger/:source (src/routes/sync.ts:20). Registering bare GET /api/cashflow and POST /api/sync will publish two endpoints that return 404 for catalog-driven clients.
Useful? React with 👍 / 👎.
| "version": "0.1.0", | ||
| "baseUrl": "https://command.chitty.cc", | ||
| "endpoints": [ | ||
| { "path": "/health", "method": "GET", "description": "Real-dependency health probe (db + chittyconnect + daemon heartbeat)", "authenticated": false }, |
There was a problem hiding this comment.
This new registration payload describes /health as a real dependency probe for db, ChittyConnect, and daemon heartbeat, but the worker still returns only the static JSON in src/index.ts:96-101. If this payload is submitted before the separate health-probe work lands, registry and certification checks will treat a simple liveness response as proof that Tier-2 dependencies are healthy.
Useful? React with 👍 / 👎.
…rface (#110) * docs(charter,chitty,claude): reclassify Tier 5 → Tier 2 platform with Tier-5 surface; add meta endpoints and dependencies Stacked follow-on to PR #106 (ADR-001 + executor registry). Documentation-only PR that brings the compliance triad and `/api/v1/status` in line with the ADR-001 amendment that landed on `feat/meta-executors-registry`. CHARTER.md / CHITTY.md / CLAUDE.md - Canonical phrasing: "Tier 2 (Platform) with Tier-5 dashboard surface" everywhere a tier is declared. - RY (Authority) row rewritten to reflect sovereignty enforcement + intent execution + multi-source ingest. No longer a pure consumer. - API contract gains the one real new endpoint introduced by #106: POST /api/v1/intents/:id/execute. Per the global no-fake-endpoints rule, the planned intent CRUD (POST /api/v1/intents, GET .../:id, GET ..., GET /api/v1/executors) is NOT documented here because it isn't implemented; it will be added when the routes are. - New Executor Registry table with canonical URI chittycanon://core/services/chittycommand/executors/{intent_type}. Lists the one executor that actually self-registers today (update_obligation_status). mercury_payment is flagged as a tracked future executor with REAL-MONEY constraints (fresh autonomous sovereignty, USD 500 per-intent cap) and explicitly NOT documented as registered. - New Cluster Runtime section: daemon is launchd/systemd, NOT a Worker; per-node L-type ChittyIDs register as sub-channels via agent.chitty.cc/api/v1/channels, NOT in the main ChittyRegister payload. - Dependencies expanded: ChittyTrust, ChittyID, chittyagent-orchestrator, chittyagent-tasks, chittyagent-ch1tty added. ChittyConnect entry expanded to call out ContextConsciousness + MemoryCloude (forever context) and sensitive-intent secret brokerage. - Compliance section flags the ChittyID re-mint as required operator action (T → P-Synthetic) and explicitly defers /health real-probes and tail_consumers wiring to separate PRs. - MCP tool count reconciled to 50 (CLAUDE.md was already correct; CHARTER/ CHITTY updated from stale "48"). src/index.ts - /api/v1/status returns tier: 2 plus tierSurface phrasing and a meta.endpoints array listing the registered intent-execute route. No other route, middleware, or handler touched. src/routes/meta.ts - /api/v1/canon returns tier: 2 + tierSurface so the public canon view matches /status and the docs. Same handler signature; no behavior change. Not in this PR (deferred): - Real-dependency /health probes (separate PR). - tail_consumers wiring to chittytrack (separate observability PR). - ChittyRegister payload submission (operator action; blocked on re-mint). - Re-mint of service ChittyID as P-Synthetic (operator action). - Intent CRUD endpoints and /api/v1/executors enumeration (future PRs). Compliance coverage: - Addresses: tier reclassification, RY language, meta endpoint surface, executor URI registry, dependency expansion, cluster sub-channel declaration (items 1, 4, 5, 7, 8 of the registration-readiness audit). - Remaining (out of scope): registration submission (item 2, operational), real /health (item 3, separate PR), tail_consumers (item 6, separate PR), P-type ChittyID re-mint (item 9, operator action). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(charter): clarify Worker vs daemon runtime split in Classification Addresses Codex P2 on PR #110: the previous wording said the Tier-2 platform and Tier-5 surface 'both run from the same worker', which contradicts the Cluster Runtime section stating daemon/ runs as a supervised launchd/systemd process, not as a Worker. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(registration): draft chittycommand Tier-2 registration payload + submission runbook (#111) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: chitcommit <noreply@chitty.cc>
1 participant
Stacked follow-on to PR #106 (
feat/meta-executors-registry— ADR-001 + executor registry). Documentation-only change that brings the compliance triad and/api/v1/statusin line with the ADR-001 amendment that landed in #106.Summary
POST /api/v1/intents/:id/execute.chittycanon://core/services/chittycommand/executors/{intent_type}). Listsupdate_obligation_status(the only currently registered executor).mercury_paymentis flagged as a tracked future executor with REAL-MONEY constraints — explicitly NOT documented as registered until its file lands.agent.chitty.cc/api/v1/channels, NOT in the main ChittyRegister service payload./api/v1/statusreturnstier: 2,tierSurface: \"Tier 2 (Platform) with Tier-5 dashboard surface\", and ameta.endpointsarray./api/v1/canonupdated identically for consistency.grep -nE \"name:\\s*'[a-z_]+'\" src/routes/mcp.ts= 50). CLAUDE.md was already correct; CHARTER/CHITTY had stale "48".Compliance audit coverage
Per the ChittyOS-compliance audit verdict on this service, this PR addresses items 1, 4, 5, 7, 8:
Remaining (out of scope for this PR):
/healthdependency probes (db / chittyconnect / daemon-heartbeat) — separate PRtail_consumers: [{ service: chittytrack }]— separate observability PRNot in this PR
/api/v1/statusand/api/v1/canontier values +tierSurfacefield touched in source.POST /api/v1/intents,GET /api/v1/intents/:id,GET /api/v1/intents,GET /api/v1/executors) is NOT documented because it isn't implemented; per the global no-fake-endpoints rule, those rows will be added when the routes land.Validation
npm run typecheck— cleanSKIP_INTEGRATION=1 npm test— 15 passed / 12 skipped (integration tests require Neon branch)grep -rn \"Tier 5\\|tier: 5\\|tier 5\" CHARTER.md CHITTY.md CLAUDE.md src/— no remaining stale references (the only "Tier-5" matches are intentional surface-name uses: "Tier-5 dashboard surface")Test plan
/api/v1/statusreturnstier: 2+tierSurfaceafter deploy/api/v1/canonreturnstier: 2+tierSurfaceafter deploy🤖 Generated with Claude Code